The state of the art for browser-based rich text editors (RTEs) (e.g., WYSIWYG—what you see is what you get) typically falls into the same pattern, the leveraging of browser support for content editable regions (e.g., for one browser this includes marking a <div> element with the content editable property set to “true”), and writing client-side script to offer additional features on top of what the browser supports (e.g., a richer way to operate on tables).
Given the browser support for content editing is nowhere near what tools such as some word processing applications can provide, RTEs add JavaScript™ on top of browser editing to offer additional features.
However, this still introduces problems. With respect to cross-browser editing, different browsers offer different levels of browser editing support in different ways. Therefore, it is difficult to implement a cross-browser implementation of the same RTE. Additionally, when JavaScript is added on top, there are browser-specific differences that make this difficult to implement.
Another problem is related to turning off content-editable features of the browser. Some browsers have content-editable features that overlap with RTEs and that are difficult or impossible to turn off. For example, one browser has special UI that appears when clicking in a table for creating rows and columns. Unfortunately, those commands do not respect the styles applied to the table for colors, fonts, and borders. In addition, this browser has a spell check feature that does not do enough; for example, the browser spell checker does not detect duplicate words such as ‘the the’ and flag one of the words as an error.
Yet another problem relates to flowing text around content. In some browsers, the only way to get browser content editability on a portion of content is to place that content in an IFrame on the page, or as previously stated, mark a content-editable attribute as “true” on a block element (<div>). This means that the content is not truly WYISWYG on the page, as the content does not follow the same HTML rules as inline text would follow, such as flowing around other content on the page such as images. The end result is that while the user can see how the content will be styled while the content is being edited, the user will not see how the content will be laid out on the page while the user is editing. However, the browser still offers some advantages that are desirable to leverage in an RTE implementation. For example, it is difficult if not impossible in a script-only implementation to leverage client text services that offer IME (input method editor) support for non-English character entry. It is also difficult to process the many clipboard formats that the client may have when pasting content into the RTE and choose the right content and format to paste into the RTE when a user executes a paste command. In both of these examples, simulating these behaviors in an RTE implementation that relied only on JavaScript would at best result in a low-fidelity facsimile.